Objective

Fix the flex container baseline computation so that it matches browsers (and the current css-flexbox-1 ED wording, https://drafts.csswg.org/css-flexbox-1/#flex-baselines) for reverse-direction containers. This is what causes Blitz to fail WPT tests css/css-flexbox/flexbox-baseline-multi-line-horiz-004.html and css/css-flexbox/flexbox-baseline-multi-line-vert-002.html.

Context

The original hypothesis was that the wrap-reverse line selection was wrong (that the first baseline should come from the first flex line in flex-line order regardless of wrap direction, per the css-flexbox-1 TR wording). However, empirical testing against Chrome (both via gentest fixtures with the container nested in a baseline-aligning flex parent, and via headless Chrome measurements of the inline baseline export) shows Chrome consistently generates the first baseline from the visually startmost line — for wrap-reverse that is the last line in flex-line order, which is what taffy already does. The current ED spec text agrees: "startmost flex line", where startmost links to the writing-mode (visual) definition of start.

The actual bug making the two WPT tests fail is on the column side: for column-reverse containers taffy took the baseline of the first item in flex order, which is positioned at the visual bottom. Browsers use the startmost (visually topmost) item, which for reverse-direction containers is the last item in flex order. In the WPT reftests it is the reference page (which uses column-reverse / single-line column containers) that taffy renders wrong, producing the observed ~15px baseline offset.

Pseudo-diff of the fix in compute_flexbox_layout:

  // line selection unchanged (visually startmost line):
  let first_line = if constants.is_wrap_reverse { flex_lines.last() } else { flex_lines.first() };
  let first_vertical_baseline = first_line.and_then(|line| {
-     line.items.iter()
-         .find(|item| constants.is_column || item.participates_in_baseline_alignment(constants.dir))
-         .or_else(|| line.items.iter().next())
-         .map(|child| child.baseline)
+     if constants.is_column {
+         // startmost item: last in flex order for reverse-direction containers
+         let item = if constants.dir.is_reverse() { line.items.last() } else { line.items.first() };
+         item.map(|child| child.baseline)
+     } else {
+         line.items.iter()
+             .find(|item| item.participates_in_baseline_alignment(constants.dir))
+             .or_else(|| line.items.iter().next())
+             .map(|child| child.baseline)
+     }
  });

New generated test fixtures cover:

• row wrap-reverse multi-line first baseline (with and without a text item participating in baseline alignment) — regression tests locking in the existing (correct) behavior
• column wrap-reverse multi-line
• column-reverse single-line (previously wrong)
• column-reverse + wrap-reverse multi-line (previously wrong)

All fixtures regenerated from Chrome via just gentest; cargo test --workspace, cargo fmt and cargo clippy pass.

Link to Devin session: https://dioxus.staging.devinenterprise.com/sessions/1674564446a64939b4972322b4f46da4
Requested by: @nicoburns